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What Cloak & Dagger is, that's what this is called, it's called Cloak & Dagger.
It's a library implementation that can be used by privacy applications such as
Nutella, I mean it's peer-to-peer, but you know, Mojo Nation, PGPnet, Freenet,
Crowds, Mixmaster, you know, what have you, Cryptobox, and it's to be used as a glue
such that if these applications wanted to integrate Cloak & Dagger functionality into it,
the user could turn on something like ultra-paranoid mode, and all traffic between two parties using this
would be entirely undetectable, that these two parties were even communicating clandestinely.
We want these parties to not even be identifiable as using Cryptobox, or whatever.
Essentially, all such privacy application traffic looks just like it mimics identically
other, less, you know, more sensor-acceptable protocols.
Just agree on a couple terms here.
Generally, the phrase cypherpunk grade generally means that the thing that it describes is extreme.
It's an absolute assurance such that if you follow, you know, the rules set for the usage of this application,
in this case, you know, normally this is going to be a cryptographic application,
then as long as you follow the rules set for the usage of this application, in this case, you know, normally this is going to be a cryptographic application,
then as long as you follow these rules, whatever guarantees that we make, they're guarantees.
Okay, this implementation is not yet cypherpunk grade, just to, you know, belay here the extremists who are going to say you're calling it cypherpunk grade.
It's not cypherpunk grade yet, we're eventually hoping that we can claim that for real, but it's getting close.
Okay, so we've got an MI6 agent out in China.
He's undercover.
Very undercover.
He's already suspect.
He's already being watched very, very closely.
All of his network traffic is being monitored, et cetera.
Okay, the first step is via traditional means, whatever that is in the spy business,
we get him or her or whatever in a suitcase.
We get a cloak and dagger enabled application to him along with a shared asymmetric key.
Very much ideally for this to work bandwidth efficiently, for this not to be incredibly slow, that box needs to be sitting,
where it's got access to a lot of local network traffic.
A lot of like, you know, as a router, something like this.
Otherwise, it's not going to be enough stuff for it to manipulate and hide within.
We're assuming some fundamental things about it.
about the operating system that this is sitting on.
It's gotta be secured.
For example, it needs to have anti-permisc detection,
such that we're gonna be sniffing traffic
and we need not be able to have it be detected
that it's doing that.
We also have to assume that it can't be compromised.
Okay, basic assumptions.
So our MI6 agent gets this box with this application on it.
He brings it up in this environment that we specified.
And what happens is local traffic sampling begins immediately.
What we're doing is we're trying to find traffic patterns.
We're looking for protocols used, who's using them,
the distributions of their usage,
just traffic patterns in general.
We're also looking for analyzing,
keeping track of payload language data.
If our payloads all around us are in Chinese,
we don't wanna start using payloads in Russian or English
or something like this.
The sites that are visited, websites, things like that,
if we're somewhere where certain sites
would be forbidden to be visited,
we don't want our application payload data
to be visiting these sites.
So if we're in Malaysia, we wanna be visiting sites
like pc.jarang.my, not something in Russian
or something like that, just basic sense stuff.
So we start sampling local traffic immediately
and we also immediately generate our PK pair.
Okay.
So this slide has generated a PK pair at this point.
Once we've determined that we've sampled enough local traffic
for it to be statistically significant,
we've got patterns built and we think that that's enough
to begin action, we need to exchange our PK pair.
For this initial exchange, the symmetric key that we,
this can basically be a one-time pad kind of, well it's not.
It's not a symmetric key, but we have to assume
the security that's in it, shared between the two peers
who are gonna be communicating there.
The symmetric key is used as input to a hash function
that determines from a list of protocols that we've,
protocol forms that we've determined
that we think are ubiquitous.
So if we think that ICMP traffic or certain forms
of telnet traffic are ubiquitous,
that no matter what network environment we're in,
those are safe.
There's gonna be a much more limited number of protocol forms
not just protocols, but what fields we use
within those protocols, the kind of data that can be
in the payloads.
There's gonna be a much more limited list
of what those protocol forms can be.
But from that list that are ubiquitous,
we've got a hash function that's keyed to those protocols.
The symmetric key is used as input to that.
And what it outputs is the protocols, fields,
sentinel values, and timing information
that we're gonna use for our initial exchange.
I'll go into that more later.
For this exchange, the symmetric key is also used
to encrypt the public key.
So that even if they were to determine
what these positions were,
we're still encrypting the public key.
Obviously we have to assure the security of that.
It's public, in this case it's not really public, public.
It's just public to our shared peer.
Using the information generated from the aforementioned hash,
the contact is initiated with a peering host,
public keys are exchanged.
Each peer, okay, okay, hold on.
The way that public keys are exchanged
is we've got these protocol forms.
And there's certain fields that we've identified
as being manipulatable.
We can change things there and,
okay, for example, we've done this local traffic sampling,
and we know that within an IP header TOS field,
there's certain values that are
statistically distributed certain ways.
We can use those fields in the statistical distribution
that we've determined.
And shared key, here's another function of the shared key.
The shared key is broken up into blocks.
Say we haven't determined what these block sizes will be.
Say 100 characters.
100 characters, whatever, per block.
When it's input into the hash function,
and this is the initial hash function here
that's just used for the exchange of PK keys
and then local traffic data.
When it's input into the hash function,
the hash function, and this is shared, realize,
so both sides are doing this at the same time,
the hash function outputs
what protocols are gonna be used next,
what fields we can use within those protocols,
what sentinel values are gonna be used
for each instance of using those fields, what time.
Timing information, how long we should delay,
which ones we should pad, which ones we should chop,
that sort of thing.
And because both sides are in tune to the same information,
they're generating the same thing from the same,
they've got the same hash function,
they've got the same symmetric key,
they're gonna, both sides are gonna be in tune to this data.
So I can use that to generate traffic,
and they're gonna be listening on that to pick it up.
Okay.
The next thing we have to do is we have to exchange
traffic pattern.
We've exchanged data.
We've exchanged keys.
Okay, question.
Because symmetric key's only gonna be used initially to,
the symmetric key isn't generally used for encryption.
We use it initially just to encrypt the public keys,
but thereafter, the symmetric key is used just to generate
the hash, or as an input to the hash,
to generate the next protocols and templates,
the next protocol forms that we're gonna be using.
It's possible that we could use the same thing,
but in various discussions,
we decided that it was more secure this way.
I don't know.
We could talk about it offline.
So we have to exchange traffic pattern data.
Both sides have been doing this local traffic sampling now
for X amount of time.
It might be a week, it might be a month,
it might be a year.
It might be a year.
We're not gonna stop,
we're not gonna move on to the next step
until we've decided, we've determined that
we've got enough traffic that we can go ahead
and start communicating securely.
We know what patterns around us look like.
So now, I compress all this data down
to the most important bits,
the traffic pattern data that my side has generated,
and I send it to my peer.
He does the same to me, using the same system
that we've just discussed for exchanging the PK keys.
Each side then diffs the other peer's copy
of their local traffic data and my copy,
and we decide on lowest common denominator,
and then that's what we're gonna use initially for,
that's gonna be an input to a separate hash function,
very similar, but a separate hash function
that determines at any given time
what protocols we're actually gonna use
and what timing information.
Question.
I was just interested in what you said,
the initial PK exchange,
I realize it's pretty symmetric to you,
but how would that hand it off
if either side had to get the classic way to change it?
If you don't have a sign that's signaling
that it won't that be detected by our ?
We're only, at this point, using protocols
that we think are ubiquitous.
Oh, that's why the map runs in a preset.
Right.
Really low time.
Right, yeah, so we might only be using
a very small number of forms,
but at this point, we don't have a lot of data exchanged,
so it's fine at this point.
Okay.
So anyway, we then diff,
diff the two traffic pattern sets,
decide on the lowest common denominator.
Now that's the input for our new hash function,
and now we're ready to begin actually exchanging messages.
Okay.
Okay.
Sure.
.
ARP spoof it.
Use , something.
You're gonna have to give it...
I have to be noticed.
That's gonna be noticed, yeah,
that's why it's set up as a rule
that you've gotta be somewhere.
.
Right.
Right.
So, like
or .
. . . . . . . . . . . . . . . . .
That's generally not advisable. We want this to be as passive as possible because anything
like that could then be detected. So we're making it an assumption that has to be there
already that we're sitting where we can see a lot of traffic without doing anything special.
That might be a hard assumption, but that's really the only way that this is going to
work.
Well, we'll stay passive. That's the thing. We'll stay, right, we don't want to do anything
active there to get more traffic. We really don't. So we're, you know, unswitched environment
or as a router where we've got a lot of things going past us. Okay. So here's how it works.
Now that we've got this new...
.
Okay, sure. I'll do that. Okay, question.
.
.
.
.
.
.
.
.
To get symmetric key sent back to them?
.
Well....
.
.
Right.
.
That's possible.
If we could exchange PK out of bound, that would be ideal.
Does that answer your question?
Sorry, I didn't even repeat the question.
But, yes?
Okay.
Here's how we hide data within the protocols.
With this other hash function,
that we've tuned to our lowest common denominators
of traffic pattern data,
we bring in symmetric key as input,
and both sides are doing this,
and we determine, say,
okay, the next packet that's going to go out
is going to be RDP,
and we're going to...
These are the possible fields that we can manipulate,
and that we can possibly change,
and it'll still look fine,
it'll be normal within our traffic distributions.
And this is the timing information,
this is how long we want to delay,
this is where we want to chop this message.
These are the sentinel values.
For each field, and each iteration,
again, based on the hash value,
we'll determine a new sentinel value.
So, for example, again, going back to the TOS field
in the IP header,
on a particular iteration,
we might determine that it's an 8-bit field,
out of the last 4 bits,
only 1 can be set at any given time to 1,
so we might say the last 4 bits are 010,
and that's our sentinel value
for that iteration, for that field.
So we've determined these things.
So I start going through the possible fields
that I can manipulate,
and I come to the first one,
I pull off a byte off my queue,
the first byte that I'm trying to send,
you know, it's sending the secret word,
and if I can put it in that field,
and there'll be a valid value
within our local traffic patterns,
then I'll go ahead and put it there.
If I can't, I place a sentinel value there.
And both sides are keyed to the same thing,
so the other side can look,
and if there's that sentinel value there,
it just skips over to the next possible field
that I can use.
This should be really obvious,
or it should start to be becoming obvious,
but this is, like, bandwidth intensive.
I mean, for every couple megs we send across,
we're just sending a couple bytes across,
so we're actually going to...
So this is intended only for the ultra-paranoid.
This is only intended for the extreme case
where you have to use this medium,
and you absolutely cannot afford to be detected,
you know.
You might die, you might get killed, whatever.
So, and we're not going to send traffic across,
you know, again,
until we feel that it's safe to do so.
We're going to match local distributions.
We don't want to significantly affect
local traffic pattern distributions.
Another thing, we're completing full sessions here.
Like, we don't want to just, you know,
send a SYN and then we move on to another protocol, whatever.
Every time we complete full sessions
within the protocol we're emulating.
And we're also fully authenticating and handshaking
and checking the data that we do send across.
They're going to send it back to us,
verify it, or send checksums, or something like that.
That hasn't been decided on.
Those are all implementation details
that we'd easily figure out later.
But there are full handshakes,
full sessions are completed every time.
And then we move to a different protocol.
And so, basically, we might be,
if we're in an environment where there's
a lot of traffic going through,
and we might, you know, every millisecond
we're switching to a different protocol,
finishing a session,
that session might take a long time to finish.
Like, you know, we'll already be moved on
to a different protocol,
but we're still finishing the first one,
things like that.
And the other side is key to the exact same data
so they know where to be,
where to receive the next bits,
they know what fields we're going to be manipulating,
and they can pull those bits off.
But otherwise, they look exactly,
absolutely exactly like a normal,
normal session of that protocol type.
Here's a little ugly thing
where it makes this implementation
really tough to do.
And this stuff I haven't implemented yet,
and it's going to take forever.
It's going to make this application massive.
The thing is, okay, one,
we've got to speak all these protocols.
But two, an active attacker could say,
well, okay, you're speaking RDP,
let me try to talk RDP to you.
So you have to be able to talk RDP
to anybody who tries to talk RDP to you.
Okay.
So all of a sudden,
you've got to have full implementations
of every protocol that you want to use.
That gets really massive.
Otherwise, the other option, I guess,
would be act like you've got a firewall in place,
some sort of filtering ACL set,
such that you're only doing RDP
with this IP address.
But what if the attacker spoofs that IP address?
Then you've still got to talk RDP with them.
So that makes it really tough.
There's one other little gotcha here.
The one noticeable thing
is that people monitoring traffic
would all of a sudden see these two hosts
who either weren't communicating at all before
or, you know, very little,
are all of a sudden communicating
on all these protocols
a whole lot just between these two hosts.
That's certainly an anomaly.
There's not a real easy solution to that,
except wait a long time
before you send more data to that host.
So it really isn't that much more, you know?
Or, I mean, you could always spoof,
you know, traffic that you send,
and then they'd spoof it to you,
and you'd sniff it off the wire.
Or you'd spoof it,
sending it to an address that isn't your peer,
but that they can sniff off the wire.
But again, that could be detectable.
That could be detected by a well-resourced Eve,
because if they could compromise the host
that you spoofed it to
and determine that they didn't really pick that up
or that they didn't initiate the connection,
then that could be detected.
So that's not really recommended either.
We're looking into doing some sort of, you know,
crowds-like system
to where there's actually a whole chain of remixing
that's happening.
So you don't always have to communicate with the same host,
but you communicate with other hosts,
and then they eventually forward the traffic back.
But right now, we don't have a good way to do that.
If we do it...
If we just did that at face value,
like something like what Mixmaster might do
or something like that,
then somewhere,
these centralized remixing hosts
are going to have to have the IP addresses of us,
and then therefore, they would know
that we're communicating,
we're part of this clandestine network.
And we can't work under that.
That's not separate from great assurances.
So we have to assume that these other hosts
might be compromised,
or rogue hosts might come up,
or something like that.
That's pretty much it.
I mean, basically, this is store-and-forward messaging.
You know, it might take forever to get messages delivered.
This is nowhere near real-time.
Question?
Yeah.
No, we're not using the same symmetric key
for the lifetime of the session.
What happens...
Thanks for bringing that up,
because I didn't mention that.
What he asked was,
are we using the same symmetric key
for deciding where we're going to...
what protocols we're going to use forever
for the entire time period.
Good morning.
Sorry to interrupt.
Some jackass is walking around
with a reject hacker exploitation fightback pamphlet,
advocating violence and damage to the hotel.
I strongly encourage you not to do that,
unless you really, really want to see
the Metro County Jail here in Las Vegas.
Okay.
If you do see him or her,
please encourage her to stop.
It's not funny.
It's causing problems.
We've been kicked out of every other hotel on the Strip.
We don't want to get kicked out of this one.
They kind of like us here,
but stuff like this makes them not like us very much,
because they really don't understand what we do.
So I would strongly encourage you, like I said,
to report this,
or at least encourage them not to do this.
I'm not advocating violence,
so please don't misunderstand me,
but we would like to see this stopped.
Which brings me to another point.
Like I said, we'd like to stay at this hotel,
and we'd like to be able to come back next year.
So far, we've had someone steal the majority of the lights
along the main row by the swimming pools.
I realize we're 13-year-olds of all ages here,
but I would strongly encourage you,
if you have the lights,
or if you know who has the lights,
or if you have other property of the hotel,
like these soap dispensers from the bathrooms.
And I don't know why you took those, man,
because you know what?
If you're dumb enough to take those,
you better be washing your hands.
So we have a general amnesty.
If you have them, no questions asked.
Return them to the NOC.
For those of you who don't know where the NOC is,
the NOC is at the very end of the building
on this side.
It's labeled.
You can't miss it.
It's where the speaker's area is.
Like I said, please bring whatever paraphernalia you have
that belongs to the hotel that you really shouldn't have.
And you know who you are.
And I'm sure you have friends who you know who they are.
So please pass the message.
We are supposed to be the brightest of the bright here.
And I have urged to string basically rope ladders
across the ceiling with some swinging tires.
So that you all can throw feces at each other.
Because you're acting like chimps.
So, like I said, I realize we're 13-year-olds of all ages.
That, however, does not exclude lame-ass pranks,
like taking the lights.
Had you hacked the PBX, I'd applaud you.
You stole the lights.
My four-year-old niece can steal the lights.
Are there any questions?
Yes, sir, stand up.
I don't, I cannot condone drunken, disorderly behavior.
Myself being an Irish Catholic,
that means I'm usually smashed by about five.
Myself also being, almost being a Jesuit priest.
That means I really get drunk by six.
Accidents happen, we understand that.
The problem is we had some people teeing up
and playing golf with the lights.
And then walking away with the lights.
Vegas has some wonderful golf courses.
If you really have the need to bring out your sticks
and to play golf, go to the golf course.
Don't use the lights.
If you find the lights, if you could please turn them in.
Like you say, if you see them broken or something like that,
nudge, nudge, wink, wink.
Bring them down to the NOC, tell us that they were broken
and you're returning it to us.
Don't set fire to the tent upstairs.
Okay, that's a very bad thing.
Once again, my four-year-old niece can do that.
You know, we expect better.
This is the Uber hacker track.
So if you're like running scripts, then you probably should be
at the other room over there where the newbies are.
So like I said, if anyone wants to come talk to me personally about it,
that's fine.
Like I said, you have general amnesty.
We will not prosecute you.
We will not beat you up and take your shoes.
We just want to make sure the property gets returned to the hotel
so we can come back so you all can come back next year.
Unless you don't want to come back.
Show of hands.
Who does not want to come back?
Okay.
Any other questions?
Anyone else have any questions?
No questions.
Very good.
I'll turn you back to your regularly scheduled programming.
Cool.
Brief interlude.
As soon as he's done with his speech,
we are going to do a spot to pet in here.
Give you a heads up.
There are two FBI agents.
One of them looks like John .
That's a little bigger.
And he's wearing a DEF CON 5 shirt.
So I'm going to get really easy on you guys.
.
Just yell.
Okay, back.
Is that addressing the question of
if we're going to use the same symmetric key
for the entire duration of the session,
which goes on basically for eternity
between these two hosts?
No.
With the messages that we're sending across,
like I briefly mentioned,
we're chopping them up, adding padding,
adding all kinds of bits of entropy.
Just definitely not sending them
as soon as the messages arrive, things like that.
Well, also to fill in the gaps
and just add a little more confusion,
when we're not needing to send in messages across,
when we're just wanting to fill in space,
then we're exchanging more data
for adding on a symmetric key
or parts of new symmetric keys.
So that changeover is constant.
Right here in the black.
Since the whole point of the covert channel
is to get as many bits through without detection as possible,
your method is extremely well-banded
with comparing the stuff that's been out there forever.
Okay, the question here is,
since the whole point of this is to get as many bits through
without detection as possible,
he says my method is very slow
compared to other methods that are out there.
Well, in looking at everything else that's out there,
this is the only way that we feel
that we can assure security and assure secrecy.
So, and it's not a concern how slow it is.
We want to make it as slow as possible
to make it secure.
Yeah, so.
He had a question, green shirt.
Since the whole point is to be as covert as possible as well,
isn't it going to be kind of odd
that there's this ongoing, like, additional traffic
between the two hosts
that weren't necessarily communicating beforehand?
Yes.
I would look for that as an anomaly.
The question is,
and I just mentioned that a little bit earlier,
but just look for, as an anomaly,
the fact that all of a sudden these two hosts
are communicating on a lot of protocols,
a lot of stuff that they weren't communicating before.
Yeah, and that's something we're working to address.
I briefly mentioned that a little while ago.
Way over there, white shirt.
.
Can you give more information?
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Yeah, the question here
is that instead of
trying to emulate all the protocols that we find
that we can get a lowest common denominator
over that might look like quite anomaly
how about if we just identify
one host or a couple hosts and then take
some features that all seem in common
and just use those as a host
profile. That's a pretty good idea
and we very much might implement
something like that. The only problem with that
is
we'd have to increase the amount of traffic that we're
using over those protocols that much more
in order to ever get significant amounts of bits across.
Other questions?
Right here, green shirt.
How about squishing packets
from a host
that appears to be web-serving and have them
sticking the data in the
packet where you're sticking it
catching it before
it gets to the host?
And then it gets dropped as soon as it got checked out?
And you have the other host
sniffing the wire before
it got dropped?
The question is how about just spoofing traffic from other hosts
and then have it sniffed off the wire
on the other end and then it'd be
dropped at the host that it actually ended up at
because it didn't match something they sent.
Yeah, I mentioned that actually.
And we can't really do that because
if an attacker compromised
either the sending host or the receiving host
and compared the messages that they've sent
and the messages actually, you know,
sent in between and the messages
received at the end
and they didn't match, then you'd be able to determine
that these other hosts were doing something in the middle.
What if that was an array of addresses
that would be locked in?
And then you do that with two hosts
but do it with several appearing hosts?
He said, what if we do this with an array of hosts?
The interesting idea there would be
if we had a whole array of sending hosts
and receiving hosts and we just,
and the sending hosts and the receiving hosts
kept state amongst themselves
and then used each other, that would help some.
But it's still, this is detectable
so we don't want to use it.
Back there, Beard.
How about using packet radio
as far as the transmission, so
and then all over again?
He says, how about using packet radio?
That's certainly a possibility.
We're trying to limit ourselves to the wire.
Matt, the guy right there.
I'm curious if this is a different method.
I've all been on Slack.
It sounds to me like you're end-to-end,
you're end-to-end connected.
There's no way you're here on the edge.
You're just wrapping it up.
What about doing something where you like,
you know, you're not seeing,
you're not seeing, you're hiding your messages
by something focused on you
and that's where you're going to be on the edge.
You're not going to be on the edge of the other end.
You're going to be on the edge of the other end.
Yes.
What's your message?
Why is that better?
He's talking about using steganography
to hide stuff inside other stuff,
inside messages, inside graphical images.
Something like that.
Post it to Usenet, post it to mailing lists
and just have other people grab it off.
Those all work very well,
but there are already systems that are working on
doing something like this.
There isn't something that does this.
So this would just be something else
to add to the arsenal.
Straight head there.
Yes.
If we needed to use stateless...
Are you talking about...
This is all state-oriented.
What if we need...
Can you say that a little louder?
Well, I mean, you could watch it anyway
and keep state, quote,
even with connectionless protocols.
Right here, question.
The basic assumption you have is that
there is a general ambient type of noise...
Noise level, floor level.
Right.
So have you thought perhaps
to try to increase the amount of traffic
for, of course,
having other folks communicating?
That might be, of course,
.
You know, you're increasing, obviously,
the amount of traffic for a number of folks.
Right.
The question here is,
because we rely on there being
a bit of ambient traffic around us,
have we thought of increasing the amount
of ambient traffic around us?
You know, manipulating it.
That's possible.
We'd have to be really careful about doing that
because then that could be detected as well.
You know what I mean?
Sure, we could throw up a bunch of other boxes around us
and have them all be real chatty.
We might do that, but I don't know.
Lots of questions.
Right here in the red shirt.
Yeah.
What happens if the central value
is the same as the data?
Very good question.
If the central value is the same as the data,
we want to send across.
Then the center value stays
and we move on to the next field
and we use the next field,
which will have a different center value.
Every field has its own center value assigned.
So we move on to the next one
and use that position.
That's a good idea.
He says, why don't we start a little bit earlier
and begin to create some of the distribution
that we're looking for.
I don't know that necessarily
we'd create the distribution we're looking for,
but just have our two hosts
begin communicating a bit earlier
before they're doing any sort of traffic
that might be detectable.
That'd need to be very changeable
because then someone might be able to look for that.
Before I take any other questions,
one other thing I want to add here real fast
that makes this implementation even bigger.
Not only do we have to emulate
all these other protocols,
but we have to emulate all these other languages
because we don't know where this is going to be used.
We have to put valid-looking payload data in these packets.
Realize right now,
we're only sneaking stuff through in headers.
Just little bits of stuff.
So we've got to be sending,
if we're sending an SMTP message,
we've got to send a piece of email.
And that piece of email can be analyzed.
And so it can't be any words
that are in our application.
We have to assume that our attacker
can get access to our application.
So...
And that's a hard problem.
I mean, that's like a linguistics problem.
We've got to be able to determine
what the local languages are
and pull words
and put together sentences that make sense
and all that kind of stuff.
And the same thing for lots, you know...
No.
Are we planning on doing any manipulation
of the source MAC address?
Generally not.
We don't want it to look like it's actually spoofed.
I mean, because then they'd be able to check that
and see that that's not actually our MAC address.
So if we were spoofing,
yes, we would and would spoof the MAC address
of the IP we're spoofing as well,
but we don't want to do that.
So you're planning on having a MAC address
that, in the case of, say,
you're going into a government facility
or some facility where they know
what internet parts they have
or what internet parts it would have.
There's a frequent spending
on one of your existing equipment.
Well, we wouldn't...
We wouldn't be placing this
in a governmental facility or something like that
where we'd be using...
I mean, we might be using existing equipment,
but...
Sure.
Sure, sure.
Absolutely.
He's saying, you know,
what if we take this machine into some place
and we place it there?
Well, it's gonna be noticed.
I mean, this new MAC address, that sort of thing.
We're not...
We're not even talking about, you know,
going and compromising PacBell or something
and sticking your machine in there.
I mean, that's outside of the realm
of what we're talking about here.
Right here.
Since you're manufacturing payloads
and putting them in your portal anyway,
do you consider using steganographic techniques
to hide stuff within the payload itself?
Yes.
The question is,
have we considered using steganographic techniques
to hide stuff within the payload itself?
We are considering that.
That'd be later on.
Working with this right now,
we're just working with the header.
Eventually, we'd like to be able
to generate graphical images
and all kinds of stuff,
generate email,
and using, you know,
hidden, basically agreed-upon words.
You know,
Apple actually means, you know,
the NSA and all this stuff
and things that would change
based on a one-time pad.
Eventually, we could add in things like that,
but we're not looking at that right now.
Red shirt.
I have a follow-up.
I'm not sure I understood
the seminal .
If you change this from one package to another,
how would the receiver know?
Oh.
Okay.
The question is,
the question is,
the sentinel values,
if the sentinel value for each field changes
on every iteration,
every protocol form,
how does the receiving host know
what sentinel value to look for?
That's generated as part of the hash.
It's also generating sentinel values
for every field that we're manipulating.
So that's agreed on in both sides, too.
I mean, they're both generating it
from the same symmetric key.
They both have access to that.
Other questions?
Right there.
.
Yes.
Yes.
He says,
should we be constantly sampling the network to adapt?
Yes, we're going to continue sampling at all times,
and we can do later exchanges of traffic data,
and, you know,
we might not change it until it's, again,
statistically significant.
You know, if 13% of this pattern changes,
then we'll begin slowly, randomly,
to begin changing our patterns
to match what it looks like around.
Another question.
Follow-up.
.
The question is,
do we do any error checking
of the data that we're transferring across?
Yes.
In the shared,
I mean, like,
we're completing every session,
and also within that,
we're doing full...
We'll probably end up doing something like FEC,
forward error correcting code,
something like that,
in order to check out there.
.
What time is the disk space
you're talking about?
Terabytes?
.
Oh, disk space or the amount of transfer
that we're going to...
.
No, probably we'll do summarization
as we capture traffic.
The question was,
how much disk space are we thinking of having to need
in order to keep all the sampled data around.
We'll do summarization.
just like an application like
MRTG does
it summarizes as it goes along
and reduces it down and so
we could easily implement something like that
other questions?
right there
yes
thank you
that's a good idea
hopefully everyone heard that
there was a couple ideas presented there
the one was instead of implementing this as a library
that we need to add the functionality
to access from
whatever, eternity servers or something like that
just implement this as
a kernel mod
or as part of the kernel
we'd have to then do that for lots of operating systems
but such that all traffic
destined for
for our peered host
automatically goes to these
we can certainly do something like that
ok
right here
is there any attempt to take advantage
of the asymmetric bandwidth
so that's
quite the idea of course
CNN is broadcasting to China
of course and so therefore
you have as much bandwidth as possible
as one, but one time
can you clarify?
well that would give you
a principle and I'll give you an example
ok so
in other words it's much easier to communicate
if you have asymmetric
if you have large bandwidth
from one to the zero sender
you could say I'm seeing a lot of work now
you're using one node basically
so you're not doing the same function
but you're relatively
is there any attempt in your
in your architecture or scheme
to take advantage of asymmetric bandwidth?
no
the question is
is there
is there any attempt within this architecture
to take advantage of asymmetric bandwidth schemes
where we've got a big pipe going in one direction
hopefully towards the clandestine covert op
and a small pipe leading back away
where we can just
single bits mean a whole lot
I'm standing here and I wink
and depending on the context that one
quote bit of data actually means a whole lot
there's nothing currently built into the system like that
but that's something very much to consider
other questions?
right here
I think like we talked about
like the MI6
right
wouldn't it be easier on the home side
to implement something on a router
that way you have immense amounts of subnets
to get traffic to
who cares for the post-drop system?
yes
very good idea
his suggestion is
in the case of something like MI6
or a well-resourced government
that's putting this into place
wouldn't it be a very good idea
to implement this on a router
where there is a lot of traffic
that's a very good idea
if we could guarantee something like that's in place
where we can actually guarantee
because it's controlled by the system
by the very people in charge of the system
that EVE isn't going to have access
to the host behind it
and we put it on a router
where it's got thousands of domains coming
lots of subnets
all these things
that works beautifully
other questions?
over there
how do you optimize the number of home systems
that you've lost on there
to make sure that the messages
to the tech board
the question is
couldn't we compromise a bunch of host systems
and then use them as a system
to filter out
and not just be communicating to one host
but communicate to lots of hosts
and we could do that
but that could be detectable
you could detect out the host
and you detect who is sending stuff to it
we kind of don't want to go that route right now
but we have to assume
a well-resourced attacker could determine that
but we can even understand
just from the way we describe it
what the user data is
on that
so you saw that
on the mic
yeah
yeah
if we're finding
that we're going to have to
like
but let's consider
develop
like
sort of
You can buy that as a droid radio in any country.
Right.
His point is with listening,
or what are called number stations,
there's already an infrastructure in place
to transmit from MI6 out to the agents.
We would just need to implement something
for the agents to talk back to MI6 via this mechanism.
That's certainly a point,
but although I'm using as an example MI6 here,
that's not really what we're thinking about.
We're thinking about more the persecuted,
political, person who's hiding,
freedom fighters, that kind of thing out,
who doesn't have this sort of resources.
There aren't number stations set up for them.
Yeah, that works in the case of NSA using this or somebody.
Other questions?
Yellow.
Hello.
how often do you use MI6?
How often do you use MI6?
The question is how often are we going to be changing sentinel values.
But I don't think that it quite makes sense.
But basically, sentinel values are different,
are unique for every single field position
and every single protocol form that we use.
Yes.
Basically, you're saying that they're going to be able to detect the sentinel values themselves,
that they are an anomaly?
No.
We're generating these sentinel values
from what we determine to be statistically significant portions
within our payload data.
And so,
it's going to look like traffic around us
and in the same distribution of traffic around us.
Anyway, I think that's it.
I think...
Last question.
Last question.
We're now doing Spot the Fed.
Okay.
If you want to talk to me,
ask me more questions offline,
we're doing Spot the Fed.
